I reviewed this at 67bd81fed75507cd94fc1d1a828a14dc084617cb. I think the centralized allowlist change correctly restores Goose and Buzz Agent across setup, readiness handoff, and default selection, and the responsive four-card layout holds. I reran the desktop typecheck, checks, 3,483 helper/unit tests, production build, and the 21 targeted onboarding Playwright cases; all passed. No code findings from me.

This currently conflicts with main in SetupStep.tsx; rebase and preserve main's clarified command-line-harness copy when resolving.

🤖 Agent-authored review.

Independent review at 67bd81fed75507cd94fc1d1a828a14dc084617cb (isolated worktree, full-file context, plus targeted Playwright probes against the --mode e2e dist build served on 127.0.0.1:4173). The allowlist centralization itself is right: ONBOARDING_RUNTIME_ORDER stays the single source of truth and SetupStep.tsx, getReadyOnboardingRuntimes, and the default-harness picker all derive from it. Three notes, one of them functional.

IMPORTANT — onboarding can persist a global default that is NotReady at spawn time

Adding buzz-agent to the onboarding allowlist makes a pre-existing gap in DefaultConfigStep.tsx reachable for the first time. buzz-agent is bundled, so auth_status is not_applicable and runtimeIsReadyForOnboarding always counts it ready — which means it can be auto-selected as the only/first ready runtime on a machine with no CLI harnesses installed. But unlike claude/codex (acpNative, no provider/model requirements), buzz_agent_requirements on the Rust side demands BUZZ_AGENT_PROVIDER, a model, and provider credentials.

Measured with buzz-agent selected in onboarding:

• provider control renders as "Select a provider", model option count = 1
• the Finish button is enabled
• persisted global config both before and after Finish: {"env_vars":{},"provider":null,"model":null,"preferred_runtime":"buzz-agent"}

Baseline with claude selected: Finish enabled, provider control count 0, preferred_runtime: "claude" — legitimately valid for a CLI-login harness. So the first-run flow now hands a brand-new user a default that fails at the very first spawn.

Cause: DefaultConfigStep.tsx:190 gates completion on only selectedRuntimeId.length > 0 && !isSaving. AgentConfigFields.tsx:354 already computes the richer configIsValid (selectedRuntimeId.length > 0 && modelIsValid && credentialsValid) and publishes it through the optional onValidityChange prop — which AgentDefaultsEditor.tsx:250 consumes but the onboarding instance does not. Minimal fix: wire onValidityChange into the onboarding AgentConfigFields and fold it into canComplete. No new validation logic needed.

MINOR — the responsive claim is 1 → 2 → 4 only above lg

Measured card geometry with 4 ready runtimes:

• 800px, 900px, 1023px: 2 columns × 2 rows (cards at y=228 / y=468, w=288)
• 1024px, 1100px, 1280px, 1440px: single row of 4 (y=326, w=236–248)

Since tauri.conf.json sets minWidth: 800, every window width from the app minimum up to 1023px renders a 2×2 grid, not one row. Fine as behavior — just worth not describing the change as a one-row layout.

MINOR — 2×2 grid clips at the app's minimum window size

At 800×500 (the configured minimum) the last card's bottom edge is at 692px while document.scrollHeight and clientHeight are both 500, so content extends past the scroll container, and the fixed footer CTA at y=346 overlaps card space. The Next button still hit-tests and reports visible at 800×500, 800×600, 1024×500, and 1280×800, so this is cosmetic rather than blocking — but going from 2 cards to 4 is what surfaced it.

Merge blocker (operational, not a code defect)

The branch conflicts with main in desktop/src/features/onboarding/ui/SetupStep.tsx. main's newer copy reads "Buzz checks for command-line harnesses on this machine…" and uses grid-cols-1 md:grid-cols-2 max-w-[592px]; the rebase should preserve main's wording while keeping this PR's lg:grid-cols-4 / max-w-[1200px] grid.

CI was green at this head (run 30111564476).